UNCLASSIFIED 


AD  NUMBER 

ADB247996 

NEW  LIMITATION  CHANGE 
TO 

Approved  for  public  release,  distribution 
unlimited 


EROM 

Distribution  authorized  to  U.S.  Gov't, 
agencies  only;  Proprietary  Info.;  19  Nov 
98.  Other  requests  shall  be  referred  to  US 
Army  Aviation  and  Missile  Command,  Attn: 
AMSAM-AC-RO-AX,  Redstone  Arsenal,  AL 
35898-5000 . 

AUTHORITY 

From  B/3  to  A/ 1 


THIS  PAGE  IS  UNCLASSIEIED 


REPORT  DOCUMENTATION  PAGE 

Form  Approved 

0MB  No.  0704-0188 

Public  reporting  burden  for  this  collection  of  information  is  estimated  to  average  1  hour  per  response,  including  the  time  for  reviewing  instructions,  searching  existing  data  sources, 
gathering  and  maintaining  the  data  needed,  and  completing  and  reviewing  the  collection  of  information.  Send  ODmments  regarding  this  burden  estimate  or  any  other  aspect  of  this 
collection  of  information,  including  suggestions  for  reducing  this  burden,  to  Washington  Headquarters  Services,  Directorate  for  Information  Operations  and  Reports,  1215  Jefferson 

Davis  Highway,  Suite  1204,  Arlington,  VA  22202-4302,  and  the  Office  of  Management  and  Budget,  paperwork  Reduction  Project  (0704-01 88),  Washington,  DC  20503. 

1.  AGENCY  USE  ONLY  2.  REPORT  DATE  3.  REPORT  TYPE  AND  DATES  COVERED 

18  JULY  1999  Final  Report  Phase  I  SBIR 

4.  TITLE  AND  SUBTITLE 

Harmonizing  Automatic  Test  System  Assets,  Drivers,  and  Control  Methodologies 

5.  FUNDING  NUMBERS 

C#  DAAH01-99-C-R021 

6.  AUTHOR(S) 

James  W.  Neiers 

7.  PERFORMING  ORGANIZATION  NAME(S)  AND  ADDRESS(ES) 

Neoteric  Technologies,  Inc. 

3077  Leeman  Ferry  Road/  Suite  B2 

P.O.  Box  4709 

Huntsville,  AL  35815 

8.  PERFORMING  ORGANIZATION 
REPORT  NUMBER 

Neo  99-05 

9.  SPONSORING/MONITORING  AGENCY  NAME(S)  AND  ADDRESS(ES) 

U.S.  Army  Research  Office  -  Washington 

AMSRL-RO-WA-SBIR 

5001  Eisenhower  Avenue  (Room  8N31) 

Alexandria,  VA  22333-0001 

U.S.  Army  Aviation  and  Missile  Command 

AMSAM-TMDE-EW  (Mr.  Mike  Locque,  Bldg.  53001) 

10.  SPONSORING/MONITORING 
AGENCY  REPORT  NUMBER 

11.  SUPPLEMENTARY  NOTES 

12a.  DISTRIBUTION/AVAILABILITY  STATEMENT 

Distribution  Unlimited  Approved  for  Public  Release 

12b.  DISTRIBUTION  CODE 

A 

13.  ABSTRACT  (Maximum  200  words) 

Report  developed  under  SBIR  contract  for  Topic  A98-I55.  It  summarizes  investigation  of  the  state  of  the 

Automatic  Test  System  (ATS)  industry  and  approaches  to  reduce  costs  of  control  software,  especially  test 
program  sets  (TPS)  and  an  investigation  to  foster  an  environment  for  the  interchange  of  instruments  without 
adversely  impacting  the  TPSs.  The  concept  of  using  generic  instrument  class  (GIC)  drivers  was  explored, 
including  the  process  for  developing  and  attaining  industry  concensus  for  using  voluntary  GIC  specifications. 

Issues  of  scope  and  utility,  generality,  consistency,  and  inclusion  of  special  features  were  explored.  Technical 
solutions  and  the  benefits  of  using  component  object  model  (COM)  objects  were  investigated.  Interchangeability 
of  digital  multimeters  using  GIC  drivers  was  demonstrated  to  not  impact  the  TPS. 

14.  SUBJECT  TERMS 

SBIR  report,  COM  objects,  instrument  drivers,  generic  instrument  class,  automatic 
test  system,  test  program  set,  software  reuse,  standards 

15.  NUMBER  OF  PAGES 

23 

16.  PRICE  CODE 

17.  SECURITY  CLASSIFICATION  OF  18.  SECURITY  CLASSIFICATION  OF  19.  SECURITY  CLASSIFICATION  OF 

REPORT  THIS  PAGE  ABSTRACT 

UNCLASSSIFIED  UNCLASSIFIED  UNCLASSIFIED 

20.  LIMITATION  OF  ABSTRACT 

standard  form  298  (Rev.  2-89) 


Pr«scnbed  by  ANSI  Std.  Z39-18 


298-102 


Ref  D 


Harmonizing  Automatic  Test 
System  Assets,  Drivers,  and 
Control  Methodologies 


SBIR  A98-155  Phase  I  Final  Report 


prepared  by 

Neoteric  Technologies,  Inc. 
P.O.  Box  4709 
Huntsville,  AL  35815 

prepared  under 

Contract  #  DAAH01-99-C-R021 
18  JUL1999 


FAX  (256)  704-5156 
VOICE  (256)  704-5154 
neotek@ro.conn 


Harmonizing  Automatic  Test  System  Assets,  Drivers,  and  Control  Methodologies  17  JUL,  1999 


FINAL  REPORT 

J.  W.  Neiers 
18  JUL  1999 


The  advent  of  the  programmable  computer  created  a  continuing  cultural  and 
commercial  dynamic  of  applying  computer  systems  to  an  increasing  number  of 
tasks  which  increases  the  demand  for  computer  components,  enables  economy 
of  scale  which  reduces  costs  and  further  enhances  the  cost  benefits  equation  for 
more  applications.  We  are  presently  in  an  environment  wherein  it  is  economical 
to  have  excess  functional  capability  to  enable  the  broadest  possible  scope  of 
applications  in  order  to  amortize  development  costs  over  the  greatest  number  of 
units.  This  is  especially  true  when  considering  the  allocation  of  functions 
between  hardware,  software,  or  micro-code.  Very  large  volume  of  demand 
fosters  the  production  of  small,  capable,  inexpensive  hardware  devices.  The 
environment  in  which  this  process  thrives  is  one  in  which  multiple  vendors  can 
produce  interoperable  components,  each  according  to  its  own  special 
technologies  and  production  expertise.  Standardized  interfaces  and  agreed 
upon  functionality  has  been  an  underlying  enabling  factor  for  this  environment. 

The  military  recognized  the  benefits  of  using  products  from  this  environment, 
designated  as  commercial-off-the-shelf  (COTS)  devices.  What  is  also  now 
realized  is  that  COTS  devices  change  rapidly  (that  dynamic  of  applications 
functionality  growth).  Consequently,  a  optical  element  in  reducing  total 
ownership  cost  for  any  system  that  requires  separate  investment  in  components 
of  that  system,  such  as  applications  software,  is  that  the  impact  of  changing 
components  does  not  adversely  affect  overall  system  performance.  This  is  of 
particular  concern  for  applications  to  automating  testing  of  sophisticated 
electronic  devices  in  military  systems. 

Such  applications  are  a  subset  of  Automatic  Test  Systems  (ATS).  In  this 
domain,  the  devices  being  tested  often  have  operational  lifetimes  measured  in 
the  decades.  The  application  software  that  controls  the  testing  is  part  of  a  Test 
Program  Set  (TPS)  that  typically  represents  a  developmental  investment  of  tens 
and  even  hundreds  of  thousands  of  dollars.  Devices  comprising  the  platform  of 
the  ATS,  including  instruments,  are  often  replaceable  for  a  few  hundred  or  a  few 
thousand  dollars  at  most.  The  capability  of  replacement  devices  such  as  COTS 
instruments  can  be  improved  with  components  costing  a  few  dollars  or 
sometimes,  even  pennies.  As  new  devices  to  be  tested  require  new  test  devices, 
the  capability  to  test  legacy  devices  and  the  utility  of  the  TPS  for  those  legacy 
devices  must  be  retained. 
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This  issue  has  been  around  since  ATSs  were  introduced  into  the  military  support 
community  to  reduce  the  total  ownership  cost  of  the  primary  weapon  system. 
Throughout  the  1970s  into  the  '80s  the  military  stressed  standard  architecture 
and  standardized  components  in  an  attempt  to  address  this  issue.  Commercial 
applications  have  currently  outrun  military  applications  so  the  military  has 
effectively  abandoned  the  concept  of  standardized  ATS  architecture  in  favor  of 
COTS.  Nevertheless,  many  of  the  interface  standards  in  the  COTS  test 
community  had  their  origin  with  the  military  standards.  At  the  same  time,  the 
ATS  community  is  sharing  many  common  issues  with  other  applications  of 
computers.  The  computer  industry,  the  software  industry,  and  now  the  internet 
community  with  its  facilitation  of  distributed  cooperative  processes,  have  all  been 
addressing  methodologies  to  reduce  the  total  ownership  cost  through  greater 
interoperability  of  heterogeneous  components,  reusability  of  software,  and 
platform  independence. 

It  is  in  this  environment  that  a  focus  on  instrument  drivers  has  a  particularly 
attractive  potential  for  reducing  the  total  ownership  cost  of  ATS  by  reducing  the 
need  to  rework  legacy  TPSs  when  instruments  are  replaced.  It  is  a  major 
premise  that  careful  attention  to  the  design  and  standardization  of  instrument 
drivers  can  greatly  increase  interchangeability  of  instruments  without  affecting 
the  application  software.  Instrument  drivers  is  also  an  area  of  technology  that  is 
unlikely  to  be  a  focus  of  other  software  and  computer  disciplines.  In  the  context 
of  this  focus  on  instrument  drivers,  the  term  instrument  includes  such  ATS 
devices  as  stimuli  and  switches  in  addition  to  conventional  instruments. 

The  context  of  an  ATS  instrument  and  its  drivers  is  illustrated  in  Figure-1 . 

To  maintain  the  focus  on  the  instrument  driver,  it  is  imperative  to  describe  the 
model  of  the  ATS  with  each  of  the  components  necessarily  not  tightly  coupled  to 
the  application  software.  Unfortunately,  this  isolation  has  not  always  been 
adhered  to  either  because  of  attempts  to  speed  performance  by  by-passing  in 
place  system  features,  lack  of  developer  discipline,  or  lack  of  adequate  system 
capability.  However,  with  currently  available  technology,  a  generic  model  as 
illustrated  in  Figure-1  can  be  maintained  with  the  resulting  benefits  of 
interchangeability  of  instruments  and  drivers  without  impact  on  the  application 
program. 

This  instrument  and  driver  interchangeability  is  premised  on  only  a  few  simple 
constraints.  One  -  The  application  program  only  communicates  with  the 
instrument  through  the  instrument  driver.  This  implies  that  the  application 
software  is  unaware  of  the  I/O  or  the  interface  to  the  instrument.  Thus,  any 
change  in  the  choice  of  instrument  interface  will  not  be  visible  to  the  application 
program.  Two  -  that  there  is  a  driver  uniquely  tailored  to  each  instrument  that 
adheres  to  certain  standardized  Application  Program  Interface  (API)  for  that  class 
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of  instruments.  Thus,  any  instrument  within  that  class  will  present  an  identical 
interface  to  the  application  software. 


Defined  by  Architecture  and  Program 


A  pair  Defined  by  Instrument 
Vendor  or  Instrument  Vendor  and 
a  3rd  Party 


FIGURE-1 

The  Role  of  an  Instrument  Driver  in  an  ATS 

In  the  extreme,  this  API  will  be  invariant  over  any  instrument  interface.  This  is 
especially  relevant,  as  new  and  more  flexible,  higher  performing  interfaces  are 
becoming  more  prevalent.  Legacy  instruments  have  RS-232,  iEEE-488,  or 
VMEbus  extension  for  Instrumentation  (VXI)  interfaces.  Most  new  instruments 
still  have  the  488  and  many  are  VXI  devices.  A  few  are  just  now  coming  as 
PCIbus  extension  for  Instrumentation  (PXI)  as  that  interface  is  getting  better 
defined.  Future  devices  will  likely  have  a  USB  or  an  IEEE-1394  or  its  equivalert. 
Thus,  instrument  interchangeability  must  include  the  ability  to  use  a  different 
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interface  to  the  computer  systems.  There  is  a  school  of  thought  that  believes 
future  computer  systems  will  have  only  two  interfaces,  USB  and  something 
comparable  to  1394. 

The  concept  of  "instrument  driver"  necessarily  is  constrained  in  this  model. 
Generally,  every  device  has  some  executable  software  that  controls  it. 
Traditionally,  for  instruments  this  was  a  combination  of  the  application  program 
and  whatever  utilities  were  provided  by  the  operating  system  or  the  specific  test 
system  environment,  which  was  frequently  called  the  "test  executive",  to  properly 
handle  details  of  the  I/O  and  specific  interface  bus  transfers  such  as  the  488  and 
standardized  488  instrument  commands.  It  is  precisely  that  integrated 
combination  of  allocation  of  functional  responsibility  that  the  "instrument  driver"  of 
this  model  avoids.  The  instrument  driver  presents  a  standardized  API  to  the 
application.  The  instrument  driver  provides  for  the  communication  with  the  I/O 
through  the  use  of  operating  system  and  environment  features  that  are 
established  when  the  driver  is  installed. 

Because  all  instruments  do  not  have  identical  functionality  or  capability,  it  is 
impossible  to  create  a  single  programming  interface  that  works  with  all  of  them. 
Like  instruments  can  be  classified  into  common  classes  with  similar  properties. 
This  will  result  in  a  taxonomy  of  classes.  Within  this  taxonomy,  many  classes  will 
share  similar  functional  properties  and  will  have  the  same  programming  interface. 
These  various  classes,  arranged  in  an  hierarchical  taxonomy  of  shared 
properties,  are  called  "generic  instrument  classes"  (GIC).  Within  a  class,  there 
are  certain  functional  properties  that  every  instrument  driver/  instrument  must 
have.  These  functions  are  the  core  functions  of  the  class.  To  accommodate 
other  instruments  with  similar  functions  but  additional  capabilities,  there  are 
"extension "  functions. 

Because  there  are  literally  thousands  of  different  instruments,  it  is  a  non  trivial 
task  to  first  classify,  then  specify,  then  implement,  and  finally  to  verify 
conformance  of  instrument  drivers  to  the  GIC  specifications.  Fortunately,  this 
concept  has  been  embraced  by  different  groups  of  the  instrument  manufacturers, 
system  integration,  and  user  communities.  Two  groups  of  particular  note  are  the 
VXIplug&play  (VXIPnP)  System  Alliance  and  the  Interchangeable  Virtual 
Instruments  (IVI)  Foundation. 

As  the  name  implies,  the  VXIPnP  Systems  Alliance  is  concerned  only  with 
instruments  that  are  VXI  plug  and  play  compatible.  However,  much  of  the  work 
of  this  group  in  establishing  frameworks,  instrument  driver  models,  distribution 
and  installation  requirements,  specification  development,  and  attention  to 
common  issues  is  applicable.  Of  particular  import  is  the  Virtual  Instrument 
Software  Architecture  (VISA)  I/O  driver  architecture  that  provides  a  unified 
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foundation  for  all  existing  points  of  view  with  platform  independence  and 
backward  compatibility. 

The  other  group  that  is  aggressively  addressing  issues  of  GIC  instrument  drivers 
is  the  IVI  Foundation.  This  is  a  recently  organized  consortium  of  companies 
chartered  with  defining  software  standards  for  instrument  interchangeability.  It 
consists  of  end-user  test  engineers  and  system  integrators.  This  group  is 
intentionally  building  on  experience  with  the  general-purpose  interface  bus  (488) 
and  VXI  systems.  The  group  is  currently  identifying  instrument  classes  based  on 
the  most  common  functionality  and  configurations  available  in  present  day  (1999) 
instruments. 


1  Work  Summary 

As  expected  when  the  project  was  first  planned,  considerable  activity  toward 
similar  ends  is  on  going  in  the  automated  test  community.  The  stated  objectives 
and  planned  tasks  stressed  the  early  assessment  of  such  activity  for  suitability  as 
effort  to  apply  and  build  upon  for  the  development  of  GIC  instrument  driver 
standards.  The  plan  also  requires  the  early  selection  of  a  suitable  standards 
setting  venue  and  establishing  a  working  position  within  that  venue. 

In  Phase  I,  we  set  out  to  determine  the  feasibility  of  using  GIC  drivers  to  enable 
the  easy  interchange  of  functionally  similar  instruments  without  having  an 
adverse  impact  on  the  TPS,  This  is  one  of  many  issues  impacting  the  reuse  of 
software.  We  recognized  the  need  to  investigate  surrounding  issues  in  context  of 
the  total  control  environment  to  avoid  situations  wherein  one  fixes  a  problem 
simultaneous  and  at  odds  with  a  similar  'fix'  in  another  segment  of  the  control 
path.  We  also  recognized  the  need  for  assessing  both  technical  feasibility  and 
the  acceptance  of  the  marketplace  or  industry  to  any  fixes  requiring  adherence  to 
standards. 

We  determined  that  the  concept  of  GIC  drivers  is  both  technically  feasible  and 
acceptable  by  a  wide  variety  of  stakeholders.  We  also  determined  that  there  is  a 
definite  convergence  of  technical  solutions  to  software  reuse  and  approaches  to 
reduce  ownership  cost  of  systems  with  digital  data  transport  or  manipulation 
functions.  This  convergence  includes  the  partitioning  and  definition  of  interface 
standards,  cooperation  among  standards  setting  bodies,  support  by  industry 
stakeholders  for  these  interface  standards,  and  a  freeflow  of  cross  industry 
segment  technologies.  The  ATS  community  is  not  an  isolated  industry  segment. 
The  same  techniques  applicable  to  reduced  ownership  costs  for  the  computer 
industry,  the  information  technology  industry,  the  software  development  industry, 
and  the  telecommunication  industry  are  applicable  within  the  ATS  community. 
Devices  and  products  are  targeted  to  serve  the  broader  markets  that  embrace 
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several  industry  segments.  The  ATS,  the  automated  calibration,  and  the 
automated  data  acquisition  segments  need  not  solve  all  of  the  associated 
problems  by  themselves.  Reliance  on  the  broader  computer  related  industries 
makes  good  business  sense. 

The  Department  of  Defense  (DoD)  sponsored  ATS  Research  and  development 
Integrated  products  team  (ARI)  working  group  came  to  a  similar  conclusion  when 
they  identified  certain  critical  interfaces  (Cl)  for  reducing  the  cost  of  ownership  for 
ATS  and  for  fostering  TPS  reuse.  One  such  Cl  is  the  instrument  driver  and  the 
GIC  concept.  Other  industry  groups,  particularly  the  VXIPnP  Systems  Alliance 
IVI  Foundation  also  focussed  on  instrument  drivers.  Because  of  the  work  of 
these  industry  consortia,  the  ARI  took  a  hands-off  approach  to  GIC 
specifications,  anticipating  progress  by  the  industry  volunteers.  In  fact,  the  IVI 
Foundation  has  made  great  progress  in  developing  appropriate  GIC 
specifications. 

Working  within  the  IVI  Foundation,  we  quickly  concluded  that  the  work  of  this 
organization  provides  an  impressive  base  for  the  purpose  of  our  research  and  we 
should  build  upon  it  for  Phase  II.  Working  within  this  organization  also  provided 
us  with  direct  contact  with  all  the  major  stakeholders  in  the  success  of  the  GIC 
concept  “  end  users,  system  integrators,  instrument  manufacturers,  and  tool  and 
development  environment  suppliers.  These  stakeholders  are  anxious  for  the 
concept  to  succeed  and  are  supportive  of  our  efforts  at  advancing  some  critical 
areas  that  are  not  feasible  with  the  current  structure  and  interests  of  the 
volunteer  organization  members.  Demonstration  of  interchangeability  of 
similar  instruments  and  measures  of  the  benefits  of  using  GIC  drivers  is 
essential  for  the  widespread  adoption  of  the  concept.  There  is  also  a  great 
deal  of  work  remaining  to  establish  the  IVI  standards  as  functioning  open 
documents  to  which  anyone  can  develop  a  compliant  driver  with  an 
assurance  of  an  acceptable  degree  of  interchangeability. 

We  accomplished  all  of  the  objectives  during  Phase  I.  We  followed  the  plan  of 
leveraging  existing  work  as  it  was  appropriate,  and  influencing  it  in  accordance 
with  our  analysis,  for  maximum  benefit  to  this  project  goals. 


2  Project  Objectives 

The  overall  objective  of  the  project  is  to  address  total  ownership  costs  of  ATS, 
especially  concentrating  on  reducing  impact  on  legacy  TPSs  when  instruments 
are  interchanged.  The  subsequent  objectives  support  this  overall  objective. 

2.1  Objective  1:  Produce  a  catalog  of  relevant  standard  activities 
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Task  1:  Survey  and  Catalog  Standardization  Effort 

Accomplishments:  Investigated  standards  setting  bodies  and  their  products  with 
relevance  to  ATS. 

Compiled  summary  of  activities  and  popular  buses  and  protocols  both 
found  in  legacy  systems  and  likely  to  be  used  in  future  systems. 

Catalogued  information  on  over  250  terms,  standards,  and  organizations 
relevant  to  project. 


2.2  Objective  2:  Assess  suitability  of  frameworks  provided  by  VXIPnP  Systems 
Alliance  and  other  relevant  organizations 

Task  2:  Investigate  VXIPnP  and  other  approaches 

Accomplishments:  Reviewed  activity  of  VXIPnP  Systems  Alliance  and  IVI 

Foundation. 

Had  numerous  discussions  with  IVI  Foundation  members. 

Investigated  Test  and  Diagnostics  Consortium  plans  and  directions. 

2.3  Objective  3:  Select  a  justified  framework  for  establishing  GIC 

Task  2:  Investigate  VXIPnP  and  other  approaches 
Accomplishments:  Assessed  alternatives  to  GIC  drivers  such  as  the 
Measurement  Subsystem  Architecture  (MSA),  use  of  standardized  expert  TPS 
generators  and  assistants,  and  standard  resources.  Concluded  GIC  drivers 
approach  is  fundamentally  most  appropriate  for  goals  of  project. 

Defined  model  of  desired  instrument  driver/  instrument  relationship  with 
the  overall  ATS. 

2.4  Objective  4:  Meet  the  requirements,  both  coordination  and  document 
generation,  of  a  specification  for  the  GICs  to  be  submitted  to  a  standards  body 

Task  2:  Investigate  VXIPnP  and  other  approaches 

Task  4:  Synthesize  Specification  to  Advance  GIC  Interoperability 

Accomplishment:  Selected  IVI  Foundation  as  body  for  initial  coordination. 

Investigated  suitability  of  GIC  drivers  and  identified  additionally  needed 
interface  modules. 

Identified  issues  and  potential  technical  impediments  to  fully  realize 
benefits  of  concept. 

2.5  Objective  5:  Validate  those  efforts  through  analysis  of  a  set  of  representative 
assets  that  include: 

Digital  Multi-Meters 

Counter-Timers 

Digitizers 
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Power  Supplies 

Task  3:  Analyze  Sample  Instrument  Set 
Digital  Multi-Meters 
Counter-Timers 
Digitizers 
Power  Supplies 

Accomplishments:  Reviewed  VXI  PnP  documents  and  IVI  Specifications. 
Specifications  and  procedures  including  organization,  approval,  frameworks,  and 
specific  classes.  All  are  in  various  stages  of  development  and  internal  approval, 
either  within  ad  hoc  working  groups  or  by  the  voting  membership  of  the 
organization.  In  addition  to  framework  and  generic  specification  components, 
twenty-five  specific  instrument  classes  have  been  identified  to  have 
specifications  generated.  Of  these,  specifications  have  been  developed  at  least 
in  draft  form  for  only  eight.  However,  these  do  include:  Digital  Multi-meter 
(IVIDmm,  IVI-5),  Counter-Timers  (IVICtr,  IVI-10),  Digitizers  (included  in 
Oscilloscope  IVIScope,  IVI-4),  and  Power  Supplies  (IVIPower,  IVI-7).  By  one 
measure,  the  availability  of  these  specifications  represents  an  initial  goal  for  the 
project.  However,  there  are  many  issues  associated  with  completeness, 
inconsistencies,  and  needs  to  meet  acceptance  as  a  viable  standard. 
Summarized  present  status  of  IVI  standards. 

Assembled  a  broad  set  of  data  for  digital  multi-meters  for  in  depth 
assessment  of  suitability  of  IVIDmm  -  IVI-5. 

2.6  Objective  6:  Develop  suitable  GICs  that  accommodate  the  representative 
assets  within  the  selected  framework 

Task  4:  Synthesize  Specification  to  Advance  GIC  Interoperability 
Accomplishment:  Began  developing  a  test  of  Multi-meter  drivers  for  HP  3458A 
and  Fluke  8840  by  writing  a  driver  for  each  in  accordance  with  IVI-5  to  perform 
only  core  functions. 

Developed  a  prototype  interface  and  demonstrated  interchangeability  of 
HP  and  Fluke  multi-meters  using  IVI  GIC  drivers  for  a  limited  subset  of  functions. 

2.7  Objective  7:  Develop  methodologies  for  classifying  generic  instruments 

Task  4:  Synthesize  Specification  to  Advance  GIC  Interoperability 
Accomplishments:  Working  with  IVI  members  on  ad  hoc  working  groups  to 
address:  Interchangeability  checking,  principles  for  class  definition,  and  value  of 
specifying  classes  in  a  language  independent  format  such  as  Interface  Definition 
Language  (IDL). 

Researched  application  of  emerging  artificial  intelligence  technology  for 
automatically  extracting  inferred  knowledge.  Technology  is  Latent  Semantic 
Analysis  (LSA)  and  appears  to  have  merit.  Assessed  approach  to  apply  it. 
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Determined  there  are  precursor  issues  that  must  be  resolved  first  using  more 
conventional  approaches.  LSA  is  still  expected  to  have  long  term  benefits. 

Identified  issues  of  generality,  truthfullness  versus  consistency,  taxonomy 
complexity,  and  naming  conventions. 

Identified  generalized  implementation  issues  with  namespaces. 

Assessed  benefit  of  COM  interface  to  increase  generality  and  utility  while 
resolving  namespace  issues. 


3  Work  Performed 

Working  within  that  context,  we  made  significant  progress  in  assessing  the 
current  state  of  consensus  of  stakeholders  in  the  GIC  driver  concept.  We 
determined  that  the  IVI  Foundation  is  the  standards  body  most  suitable  to  work 
within  toward  bringing  the  GIC  driver  concept  to  fruition.  We  performed  studies 
that  focused  on  the  following  areas. 

3.1  Industry  Wide  Standards  and  Interoperability  Attempts 

We  assessed  the  various  standards  setting  bodies  for  relevance  and  selected  the 
IVI  Foundation.  Of  the  hundreds  of  organizations  determining  standards,  over  50 
are  involved  with  standards  that  have  a  potential  of  direct  impact  on  ATS  and 
instrument  interchangeability.  Some  such  as:  1394  TA,  PC/i04  Consortium,  PCI 
SIG,  PCMCIA,  PICMG,  EIA,  VESA,  and  VITA  have  an  emphasis  on  form  factor, 
mechanical  dimensions,  and  bus  protocol.  For  an  identification  of  the  acronyms 
of  the  standards  setting  organizations  referenced  herein,  see  Table  1.  Others 
such  as  ANSI,  ISO,  ITU,  and  lEC  are  more  formal  bodies  and  are  reachable  only 
after  standards  have  been  accepted  by  industry  and  proven  workable  first  as 
voluntary  ad  hoc  standards.  Others  such  as:  the  Active  Group,  COS,  OMG,  and 
the  Open  Group,  while  having  a  direct  impact  on  software  reuse  and  potentially 
GIC  implementation,  are  not  the  proper  venue  for  GIC  standardization. 

3.2  Existing  Organizations  and  Relevant  Legacy  Work 

Standards  setting  groups  of  particular  import  to  this  project  are:  IVI  Foundation, 
VXIPnP  Systems  Alliance,  ARI,  ODAS,  Test  and  Diagnostics  Consortium,  and 
certain  working  groups  within  the  IEEE.  Each  of  these  appears  to  be  maintaining 
liaison  with  each  other  so  our  work  within  the  IVI  Foundation  seems  to  be  well 
placed  for  the  purpose  of  promoting  open  specifications.  We  studied  the 
documents  already  available  from  the  IVI  Foundation  within  the  context  of  other 
activities  with  common  goals. 


3.3  GIC  Driver  Feasibility 


Harmonizing  Automatic  Test  System  Assets,  Drivers,  and  Control  Methodologies  17  JUL,  1999 


We  assessed  the  feasibility  of  the  GIC  driver  concept,  compared  it  to  alternate 
approaches,  and  described  the  results  in  a  paper  "Reducing  Total  Ownership 
Costs  of  a  Test  System  with  Standardized  Device  Drivers",  March  19,  1999. 


Table  1  Organizations  Affecting  Instrument  Interchangeability 


ACRONYM 

ORGANIZATION 

NAME 

PRINCIPAL  AREAS  OF  INTEREST  TO  ATS 

1394  TA 

Firewire  Trade  Association 

Defining  high  speed  bus  protocol 

Active  Group 

Accelerating  ActiveX  interoperability  as  an  open  standard 
compatible  with  the  Open  Software  Foundation’s  Distributed 
Computing  Environment 

ANSI 

American  National  Standards 
Institute 

Primary  US  standards  coordination  body  and  US  member  of 

ISO  and  lEC 

ARI 

Automatic  Test  Systems 
Resources  Interface 

DoD  sponsored  group  addressing  specific  issues  of  TPS 
portability,  reusability,  instrument  interchangeability,  and  cost 
of  ownership  of  ATS.  Defined  critical  interfaces,  including  GIC 

COS 

Corporation  for  Open  Systems 

Offer  architectural  guidance  and  open  standards  for 
interoperable  computer  and  communications  equipment  and 
services 

EIA 

Electronic  Industries 

Association 

Signal  and  communications  interface  standards  such  as  RS-232- 
C  and  other  serial  buses  and  connectors 

lEC 

International  Electro-technical 
Commission 

Test  procedures,  interfaces,  definitions,  networks,  and  all  related 
electrical  and  communications  elements 

IEEE  WG 

Institute  of  Electrical  and 
Electronic  Engineers  Working 
Groups 

Test  and  measurements  buses,  protocols,  languages,  resources, 
and  ATS  related  standards 

ISO 

International  Organization  for 
Standardization 

World  wide  standards,  including  measurement,  data  encoding, 
signal  processing,  and  all  related  elements 

ITU 

International 

Telecommunications  Union 

Telecommunications  protocols,  regulations,  frequency 
allocations.  Formerly  CCITT 

IVI 

Foundation 

Interchangeable  Virtual 
Instruments  Foundation 

Generic  Instrument  Class  drivers  to  promote  instrument 
interchangeability 

ODAS 

Open  Data  Acquisition 

Systems 

A  consortium  of  PC  plug-in  data  acquisition  card  vendors 
defining  drivers  for  Common  Object  Model  (COM)  standard 
interface  to  assure  interchangeability  and  interoperability 

OMG 

Object  Management  Group 

Object  oriented  software  development  and  management  for 
interoperability,  portability,  and  reuse 

Open  Group 

Global  open  information  infrastructure  for  interoperable, 
portable,  and  reusable  software  and  data 

PC/104  C 

Personal  Computer  /1 04 
Consortium 

Specifications  for  embedded  PC  applications  and  devices 
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ACRONYM 

ORGANIZATION 

NAME 

PRINCIPAL  AREAS  OF  INTEREST  TO  ATS 

PCI  SIG 

Peripheral  Components 
Interconnect  (PCI)  Special 
Interest  Group 

Specifications  for  small  PCI  and  embedded  devices 

PCMCIA 

Personal  Computer  Memory 
Card  International  Association 

Standards  for  PC  Card  devices 

PICMG 

PCI  Industrial  Computer 
Manufacturers  Group 

Specifications  for  backplane  electrical,  mechanical,  and  signal 
compatibility 

T&DC 

Test  and  Diagnostics 
Consortium 

Improved  interoperability  between  test,  built-in  test,  diagnostics, 
and  maintenance  for  commercial  systems 

VESA 

Video  Electronics  Standards 
Association 

Interoperable  displays  and  their  interfaces 

VITA 

VMEbus  Industry  Trade 
Association 

Standards  for  VME  devices 

VXI  PnP  SA 

VMEbus  extension  for 
Instrumentation  (VXI)  Plug  & 
Play  Systems  Alliance 

Plug  in  interoperability  of  VXI  devices 

3.4  Status  of  IVI  Foundation  Standards 

A  fourth  study  performed  during  this  period  was  an  assessment  of  the  status  of 
the  IVI  Foundation  documents  and  an  identification  of  relevant  issues.  The 
status  progresses  from  "proposed"  through  "draft"  to  "accepted".  When 
proposed,  those  deemed  most  urgent  are  assigned  to  a  working  group  for 
development.  Likewise,  as  issues  are  uncovered,  ad  hoc  working  groups  will 
study  them  and  make  recommendations.  Once  a  specification  is  assigned  to  a 
working  group,  the  group  chair  will  produce  a  draft.  It  will  then  move  through 
discussion  and  review  with  eventual  acceptance  by  the  entire  voting  membership 
of  the  foundation.  At  that  point,  it  will  be  published  for  trial  use  with  expectations 
of  revisions  and  eventual  forwarding  to  a  more  formal  standards  setting  body. 

The  IVI  Foundation  has  the  following  documents  in  some  degree  of  development. 
The  status  of  each  of  the  IVI  documents  is  shown  in  Table  2. 

In  addition  to  those  documents  listed  in  the  table,  the  following  instruments  have 
been  proposed  for  GIC  specifications:  DWG/Bus  Emulator,  Network  Analyzer, 
Serial  Word  Generator,  1553  Bus  Emulator,  Precision  DAQ,  Set  Point  Controller, 
Noise  Figure  Meter,  Logic  Analyzer,  Synchro/Resolver,  Voltage  Comparator, 
Audio  Analyzer,  Simple  Analog  I/O,  RF  Signal  Generator,  Serial  Bus,  Time 
Stamp,  and  Static  Digital  I/O. 
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Table  2  --  Status  of  IVI  Foundations  Specifications 


ID 

Title 

Date 

Rev 

Status 

Instrument 

IVI-1 

Charter  Document 

Aug.98 

1.0 

Accepted  w/ 
modification 

NA 

IVI-2 

Operating  Procedures 

Jul.98 

0.3 

In  Review 

NA 

IVI-3 

Ivi  Class  Specification 

In  Review 

NA 

IVI-3.1 

Ivi  Architecture  Overview 
Specification 

Jan. 98 

0.1 

In  Review 

IVI-3.2 

Ivi  Inherent  Capabilities 
Specification 

Jan. 98 

0.2 

In  Review 

IVI-4 

IviScope  Class  Specification 

Aug.98 

1.0 

Accepted 

Oscilloscope 

IVI-5 

IviDmm  Class  Specification 

Aug.98 

1.0 

Accepted 

Digital  Multi-meter 

IVI-6 

IviFgen  Class  Specification 

Aug.98 

1.0 

In  Review 

Function  Generator 

IVI-7 

IviPower  Class  Specification 

Aug.98 

1.0 

Accepted 

Power  Supply 

IVI-8 

IviSwitch  Class  Specification 

Aug.98 

1.1 

Accepted 

Switches 

IVI-X.X 

Ivi  Digital  Class 

In  Review 

Digital 

IVI-1 0 

IviCtr  Class  Specification 

Jan.99 

0.3 

DRAFT 

Counter 

IVI-1 1 

IviSpcAN  Class  Specification 

Jan. 99 

0.4 

In  Review 

Spectrum  Analyzer 

IVI-1 2 

IviPwMtr  Class  Specification 

Jan.98 

0.4 

In  Review 

Power  Meter 

From  the  viewpoint  of  this  project,  we  assessed  the  following  areas  as  requiring 
refinement: 

1)  The  details  within  the  specifications  are  insufficient  for  unambiguous 
implementations. 

2)  There  is  a  need  for  more  complete  definition  of  the  higher  level  objects 
in  the  class  structure.  These  are  intended  to  be  addressed  by  the  IVI-3.1  and 
IVI-3.2  specifications,  which  are  both  in  very  early  stages  of  development. 

3)  There  is  a  need  for  a  methodology  to  verify  conformance  and  to  test 
interchangeability  of  driver  implementations. 

4)  There  is  a  need  for  tools  to  identify  class  membership  and  even 
potentially  the  need  for  either  a  methodology  or  a  specification  for  defining  class 
membership.  This  implies  a  need  for  a  rigorous  taxonomy  of  GIC  objects. 

Discussions  with  Foundation  members  confirmed  that  some  empirical 
demonstration  of  interchangeability  and  some  comparison  of  drivers  developed  in 
accordance  with  the  IVI  specifications  against  other  drivers  would  be  extremely 
beneficial  toward  helping  the  GIC  driver  concept  mature.  There  needs  to  be  a 
much  more  specific  definition  of  the  software  architecture  into  which  the  specific 
class  specifications  fit.  This  may  require  major  revisions  to  existing  3.x 
documents  or  additional  ones.  A  particularly  important  segment  that  must  be 
resolved  is  how  to  specify  required  functions  that  are  now  tacitly  performed  by 
proprietary  software. 
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Present  implementations  of  IVI  GIC  Drivers  are  heavily  dependant  upon  the 
proprietary  National  Instrument's  (Nl)  LabVIEW  or  LabWindows/CVI  Application 
Development  Environment  (ADE).  This  environment  includes  a  library  of  useful 
reusable  code  segment  and  help  in  the  form  of  a  wizard  to  walk  a  developer 
through  the  use  of  templates  to  produce  instrument  drivers  efficiently  and 
uniformly.  This  package  includes  an  "IVI  Engine"  that  provides  some  degree  of 
compliance  checking.  The  degree  to  which  this  library  and  tools  will  become 
available  through  a  "constrained  public  domain"  grant  by  Nl  to  the  IVI  Foundation 
is  still  under  discussion.  Theoretically,  one  is  not  constrained  to  use  the 
proprietary  Nl  tools,  and  with  some  development,  the  work  of  the  IVI  Foundation 
should  be  beneficial  to  developers  using  other  ADEs  such  as  Hewlett-Packard's 
(HP)  VEE,  TYX's  PAWS,  Visual  BASIC,  or  C++.  This  is  an  area  of  the  3.x 
specifications  in  much  need  of  work.  Discussions  with  both  Nl  and  HP  have  led 
us  to  identify  the  importance  of  providing  some  statistically  significant 
demonstration  of  interchangeability  and  measures  of  resulting  work  both  with  and 
without  the  use  of  IVI  compliant  GIC  drivers.  Our  lessons  learned  and  efforts 
directed  toward  these  specifications  will  significantly  advance  the  "methodology" 
for  GIC  driver  development  to  achieve  instrument  interchangeability.  An 
especially  productive  effort  would  be  the  demonstration  and  development  of 
appropriate  documents  for  COM  interfaced  drivers.  This  would  likely  require  an 
additional  3.*  specification.  The  resulting  metrics  and  capture  of  methodology 
will  be  extremely  important  to  the  widespread  acceptance  of  the  GIC  driver 
concept. 

Once  GIC  driver  specifications  are  developed  for  the  more  prevalent  instruments 
such  as  Digital  Multi-Meters,  Oscilloscopes,  Function  Generators,  Power 
Supplies,  and  Switches,  the  tasks  become  increasingly  difficult.  It  is  easy  to 
have  a  proliferation  of  generic  classes,  thus  negating  the  benefits  for 
interchangeability.  Likewise,  it  is  difficult  to  properly  categorize  many 
instruments.  The  problem  is  exacerbated  by  different  usage  for  identical  terms 
by  different  manufacturers.  One  technique  we  discovered  is  the  use  of  Latent 
Semantic  Analysis  (LSA)  as  a  tool  to  aid  in  classifying  an  instrument  function  and 
in  verifying  compliance.  This  technique  could  help  resolve  different  usage  in 
technical  manuals  from  the  usage  of  identical  words  in  the  IVI  specifications. 


3.5  Latent  Semantic  Analysis 

The  technique  of  LSA  may  be  quite  suitable  to  addressing  the  issues  of  class 
membership,  specification  development,  consistency  checking,  driver  writing, 
and  conformance  checking.  We  briefly  investigated  this  technology  during  the 
Phase  I  effort. 
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LSA  is  a  mathematical/statistical  technique  to  capture  essential  relationships 
between  text  documents  and  word  meaning,  or  semantics.  Statistical 
computations  are  applied  to  large  bodies  of  text  to  determine  and  represent 
words  of  similar  meaning  in  context,  even  though  the  same  word  may  not  even 
appear  in  two  documents  being  compared.  For  instance,  the  word  'period'  may 
be  equated  to  'time  interval'  based  solely  on  similar  contextual  usage.  If 
manufacturers'  of  different  types  of  instruments  used  'period'  with  different 
underlying  definitions,  that  also  could  be  detected. 

The  underlying  theory  of  LSA  is  that  any  usage  of  a  word  in  context  is  latently 
associated  with  a  similarity  of  meaning  of  words  and  sets  of  words  in  relation  to 
each  other,  along  with  mutual  constraints  as  to  what  is  meant  and  what  is  not 
meant.  Since  LSA  originated  within  the  cognitive  science  community  and 
artificial  intelligence  researchers'  attempt  to  model  human  language  learning, 
some  of  the  description  can  be  rather  esoteric.  The  fact  is  it  has  been 
demonstrated  as  effective.  Given  a  college  freshman  psychology  text-book,  the 
LSA  could  correctly  answer  the  multiple-choice  questions  to  pass  the  course. 
Scores  have  been  shown  to  overlap  human  performance  in  several  areas  such 
as  standard  vocabulary,  subject  matter  tests,  sorting,  and  category  judgement. 

The  process  is  totally  unsupervised,  meaning  that  human  intervention  or  training 
of  any  classifier  is  not  required.  It  is  not  a  traditional  natural  language  process  in 
that  there  is  no  human  constructed  semantic  knowledge  base  required.  There  is 
no  semantic  network,  grammar,  or  syntactic  parser  involved.  Rather,  only  the 
statistical  pattern  of  the  bits  representative  of  words  (you  pick  the  language), 
glyphs,  or  other  picture  characters  is  processed.  In  a  practical  application  for 
GIG  driver  development,  the  data  would  be  the  ASCI  representation  of  English 
text  such  as  is  found  in  the  IVI  Specifications  and  instrument  manufacturers' 
operating  manuals  and  other  descriptive  documents. 

To  envision  the  concept,  consider  a  simple  paragraph  of  n  sentences.  Each 
sentence  is  a  concept  and  is  represented  as  a  column  in  a  matrix.  Each  of  the 
unique  words  is  a  row  in  a  matrix.  Each  cell  in  the  resulting  mxn  matrix  will  be 
assigned  a  number  for  each  occurrence  of  the  word  in  the  concept  (sentence). 
Each  ceil,  with  the  frequency  of  occurrence,  is  then  weighted  by  a  function  that 
expresses  the  importance  of  a  word  in  the  context  and  the  degree  to  which  it 
carries  information  about  the  domain  of  interest.  Words  like  'a'  and  'the'  are 
essentially  removed  from  the  analysis. 

Next,  singular  value  decompositions  (SVD)  is  applied  to  the  matrix.  This  is  a 
type  of  matrix  mathematics  called  factor  analysis.  In  SVD,  a  rectangular  matrix  is 
decomposed  into  the  product  of  three  other  matrices.  One  component  matrix 
describes  the  original  row  entities  as  vectors  of  derived  orthogonal  factor  values. 
Another  component  matrix  similarly  describes  the  original  columns.  The  third 
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component  is  a  diagonal  matrix  containing  scaling  values  such  that  when  the 
three  components  are  matrix-multiplied,  the  original  matrix  is  reconstructed.  The 
coefficients  at  the  large  dimensions  of  the  diagonal  matrix  are  of  ever  diminishing 
importance  and  can  to  be  truncated,  effectively  compressing  the  resulting  matrix 
dimension,  with  little  loss  of  information. 

In  practice,  contextual  meanings  of  words  can  be  determined  by  statistically 
analyzing  large  bodies  of  textual  information  such  as  encyclopedia,  or  for  the  GIC 
driver,  Autotestcon  and  ATE&C  conference  proceedings  and  various  technical 
journals.  The  resulting  vectors  are  millions  of  elements  long.  Application  of  SVD 
can  reduce  the  matrix  dimensionality  to  a  practical  workable  size.  Research  in 
LSA  has  determined  that  the  greatest  accuracy  of  semantic  correlation  occurs 
when  the  resulting  matrices  are  on  the  order  of  200  to  500. 

LSA  should  be  considered  as  a  potentially  powerful  adjunct  tool  for  improving  the 
efficiency  of  determining  instrument  class  membership  and  for  validating 
resultant  class  drivers.  However,  its  suitability  is  tempered  by  the  newness  of  the 
technique  and  the  fact  that  there  is  much  room  for  first  making  progress  in  the 
development  and  acceptance  of  GIC  instrument  drivers  using  conventional 
techniques. 

3.6  COM  Objects 

Component  Object  Models  (COM)  objects,  are  reusable  binary  software 
elements  or  objects.  COM  is  a  standard  that  enables  these  objects  to 
communicate  without  requiring  recompilation  and  linking  of  the  entire  system 
every  time  one  object  is  changed.  The  importance  of  this  is  achieving  awareness 
within  the  information  technology  community  and  will  be  even  more  relevant  for 
the  ATS  community  as  a  way  to  alleviate  identified  problems  with  GIC  instrument 
drivers. 

A  COM  object  is  language  independent.  It  can  be  generated  using  a  language  of 
choice.  It  will  conform  to  certain  interface  communication  standards  that  enable 
any  program  to  invoke  the  functions  of  the  object.  This  sounds  almost  like  magic 
and  too  good  to  be  true.  Yet,  through  an  established  standard  for  generating  a 
globally  unique  identifier  (GUID),  the  use  of  a  registry,  and  standards  for 
communicating  the  fundamental  parametric  requirements,  COM  objects  can  be 
reused  within  or  outside  the  calling  process  and  across  platforms  without  regard 
to  the  physical  location  of  the  various  software  elements,  the  computers,  or  the 
environments. 

This  is  a  powerful  concept  that  has  a  great  potential  for  the  GIC  driver  concept.  It 
avoids  the  unmanageable  growth  of  unique  names  encountered  with  the 
management  of  GIC  source  code.  The  TPS  can  communicate  with  the  driver 
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API  without  requiring  the  overhead  of  mapping  the  different  functions'  names  to 
an  established  neutral  set.  The  present  IVI  standards  begin  all  names  with  the 
instrument  manufacturer's  name  so  the  same  function  must  have  a  different 
name  for  each  instrument,  thus  guaranteeing  innate  incompatibility.  This 
approach  is  practical  from  a  configuration  standpoint  but  presents  a  problem  for 
easy  interchangeability  without  impact  on  the  controlling  software.  The  use  of 
COM  objects  avoids  this  problem. 

Of  even  greater  significance  is  the  potential  for  decomposing  intricate  functions 
into  primitives  or  atomic  elements.  Some  complex  instruments  such  as  a 
calibrator  or  the  various  digital  bus  emulators  could  be  synthesized  by  the  easy 
integration  of  atomic  COM  objects. 


3.7  Interchangeability 

Interchangeability  of  assets  is  the  ability  to  replace  a  given  asset  with  an 
alternative  asset  of  sufficient  capability  but  of  different  design  or  manufacture. 
One  hundred  percent  interchangeability,  meaning  all  functionality  all  of  the  time 
for  every  instrument  in  a  class  is  unrealistic  and  unachievable  with  finite 
resources.  However,  even  a  substantial  degree  of  interchangeability,  such  as  80 
percent  of  the  functions  80  percent  of  the  time  is  a  worth  while  goal.  Another 
measure  is  that  on  average,  the  amount  of  rework  required  when  interchanging 
instruments  is  reduced  to  a  small  part,  such  as  20  percent,  of  that  traditionally 
required. 


3.8  Interoperability 

Interoperability  of  applications  is  the  ability  to  run  a  given  application  program  or 
TPS  on  multiple  physical  configurations  of  test  equipment. 


3.9  Other  Issues 

Other  issues  were  deemed  important  to  the  overall  success  of  the  GIC  driver 
concept,  but  as  less  critical  for  immediate  implementation.  Initial  examples 
included  :1)  the  relevancy  of  the  Measurement  Subsystem  Architecture  (MSA)  or 
its  alternate  name  Measurement  Stimulus  Subsystem  (MSS),  2)  the  need  for 
language  independence  of  the  specification,  and  3)  Class  Taxonomy  and 
treatment  of  complex  hybrid  devices. 
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4  Experimental  Work/Test  Procedures 

As  a  means  to  verify  the  basic  concept  of  enabling  instrument  interchangeability 
using  GIC  drivers  that  conform  to  the  IVI  Foundation  GIC  Specifications,  we 
experimented  with  some  of  the  products  produced  by  the  IVI  Foundation 
members.  The  GIC  specification  IVI-5,  IviDmm  Class  Specification  was 
sufficiently  developed  that  conforming  drivers  could  be  written.  National 
Instruments  (Nl)  had  written  and  made  available,  conforming  drivers  for  both  the 
HP3458a  and  the  Fiuke8840a  multi-meters.  These  were  written  to  work  with  the 
Nl  proprietary  IVI  Engine,  although  the  intent  is  for  the  IVI  Foundation  with  the 
help  of  Nl  to  provide  a  non  proprietary  less  capable  version.  Only  a  small  part  of 
the  functionality  is  required  for  using  the  IVI  compliant  GIC  drivers.  We  wrote 
alternative  software  to  negate  the  need  to  use  the  Nl  IVI  Engine  and  that  enabled 
a  visual  interface  to  control  and  simulate  the  calls  from  a  TPS  to  the  multi-meter. 
We  successfully  demonstrated  interchangeability  of  different  manufacturers' 
instruments  using  the  GIC  driver  concept. 


5  Design 

Not  applicable 


6  Test  Equipment 

Hewlett-Packard  3458a  digital  multimeter 
Fluke  8840a  digital  multimeter 
Hewlett-Packard  E363a  power  supply 
Fluke  5700a  Calibrator 


7  Test  Performed 

Demonstration  of  similar  voltage,  current,  and  resistance  measurements  from  the 
same  interface  using  calls  to  each  of  the  Hewlett-Packard  and  Fluke  digital 
multi-meters. 


8  Failures 
None 
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No  unforeseen  problems  have  been  encountered. 


10  Issues 

There  are  several  issues  concerning  the  best  technical  approach  to  maximize 
instrument  interchangeability  while  minimizing  adverse  impact  on  control 
software.  These  issues  generally  arise  from  the  need  for  consensus  among  all 
stakeholders  and  the  natural  tendency  for  each  to  want  to  postpone  any  personal 
impact.  Because  of  the  breadth  of  participation  in  the  IVI  Foundation,  cross 
membership  in  other  organizations  with  related  goals,  and  established  liaison 
functions  among  standards  setting  organizations,  we  expect  all  these  issues  to 
be  resolved  in  due  time.  However,  this  natural  time  constant  may  be 
unnecessarily  long.  A  judicial  application  of  resources  to  specific  areas  will 
accelerate  benefits  of  reduced  ownership  costs.  The  following  identification  and 
discussion  of  some  specific  issues  should  offer  some  guidance  as  to  what  those 
areas  are. 

10.1  Buses 

The  ATS  community  has  traditionally  restricted  itself  to  issues  of  the  external  I/O 
computer  buses  directly  interfacing  to  instruments.  These  are  usually  limited  to 
such  serial  buses  as  RS-232,  RS-422  and  423,  RS-485,  the  IEEE-488,  and 
VXIbus.  Interfaces  to  these  buses  are  sufficiently  isolated  from  the  GIC  drivers 
that  they  need  not  be  a  factor  in  the  development  of  GIC  driver  specifications. 
However,  with  the  increased  distribution  of  computational  resources  in  the  prime 
systems  and  an  increasing  emphasis  on  built-in-test  and  diagnostics  in  the  prime 
systems,  consideration  of  other  emerging  buses  is  a  must.  Higher  transfer  rates 
using  the  cross  bar  switches  and  fabric  concepts  for  VMEbus  and  PCIbus  based 
chassis,  miniaturized  formats  built  around  the  PCIbus  protocol,  and  fundamental 
changes  in  computer  architecture  with  the  universal  serial  bus  (USB)  and  firewire 
(IEEE-1394),  will  drive  the  reallocation  of  functions  in  all  computer  controlled 
systems.  This  directional  change  will  impact  the  utility  of  GIC  drivers  and  their 
long  term  benefits.  Proper  consideration  now  will  assure  their  beneficial  position 
in  the  changing  environment. 

10.2  Names,  Labels,  and  Hierarchies 

This  seemingly  non-technical  issue  is  at  the  heart  of  most  of  the  discussions  in 
arriving  at  consensus  for  specifications.  As  generality  is  stretched  to  increase 
the  scope  of  a  particular  element,  the  greater  are  the  incompatibilities  that  are 
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identified.  The  dichotomy  of  preceding  a  function  name  with  the  unique 
instrument  manufacturer's  name  was  previously  discussed.  This  aids 
configuration  management  of  the  documentation  but  hinders  interchangeability. 

Consistency  across  instruments  is  also  at  issue  as  analogous  functions  may  take 
on  entirely  different  meanings  for  different  instruments.  This  is  a  consistency 
versus  truthfulness  notion.  From  a  human  standpoint,  it  is  desirable  that  the 
structure  of  the  APIs  to  each  GIC  driver  be  consistent,  even  to  using  identical 
names.  Yet  it  is  not  desirable  that  a  word  like  'READ'  means  'WRITE'  when  the 
instrument  changes  from  a  sensing  and  measurement  device  to  a  signal 
generation  device. 

The  whole  taxonomy  of  GICs  soon  becomes  an  issue  once  the  simple  multi¬ 
meters,  scopes,  and  power  supplies  are  accommodated.  Digital  bus  emulators 
and  special  purpose  complex  devices  such  as  calibrators  are  difficult  to  treat  as 
generic.  Too  fine  a  granularity  and  the  set  has  a  population  of  one.  Too  course 
a  granularity  and  the  useful  functions  are  not  accommodated.  At  immediate 
issue  is  whether  to  ignore  those  more  complex  devices  or  to  address  them  with  a 
more  sophisticated  technical  arsenal  such  as  through  assemblages  of  COM 
objects. 

10.3  Organizational  Efforts 

This  is  hardly  a  technical  issue,  but  it  is  an  issue  impacting  the  speed  of  success 
for  the  GIC  driver  concept.  The  IVI  Foundation  is  the  single  organization  with  the 
primary  focus  on  promoting  GIC  drivers.  The  organization's  effort  has  initially 
concentrated  on  developing  specifications  for  the  more  commonly  encountered 
devices  as  illustrated  in  Table  2.  There  have  been  a  limited  number  of  technical 
investigation  tasks  performed  within  the  organization.  The  limitations  of  a 
volunteer  organization  necessarily  limits  the  quantity  of  such  tasks  that  can  be 
accomplished. 

There  is  still  an  open  issue  as  to  the  long  term  operating  functions  such  as 
education,  promotional  materials,  and  resource  sharing.  There  are  presently  no 
provisions  nor  incentives  to  encourage  members  to  develop  drivers  and  to  make 
them  available  to  either  the  membership  or  the  ATS  community  at  large. 
Resolving  such  issues  will  impact  the  rate  of  acceptance  of  the  GIC  driver 
concept  and  the  resulting  payback. 

10.4  COM 

The  adherence  to  and  the  requirements  for  COM  standards  is  yet  to  be 
addressed.  The  present  position  of  the  IVI  Foundation  is  to  not  prohibit  the  use 
of  COM  and  appears  to  be  one  of  favoring  it.  From  a  technical  standpoint,  COM 
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will  alleviate  many  of  the  anticipated  problems.  Full  adoption  of  COM  will 
possibly  enhance  acceptance  of  the  GIC  driver  concept.  However,  near  term 
ambivalence  does  not  seem  detrimental. 


11  Results 

The  results  of  the  Phase  I  effort  far  exceeded  the  objectives,  primarily  because  of 
exogenous  activities.  Other  end  users  and  stakeholders  in  the  ATS  and  TPS 
community  perceived  a  similar  need  and  cooperated  in  the  IVI  Foundation  to 
advance  the  GIC  driver  concept.  We  were  aware  of  this  activity  at  the  start  of 
Phase  I  and  extended  our  assessment  of  the  state  of  the  ATS  industry  to  include 
a  concentrated  assessment  and  comparison  of  the  IVI  Foundation's  scope, 
processes,  products,  and  status. 

As  a  result  of  this  study,  the  following  statements  are  justified: 

1 )  This  study  resulted  in  a  current  assessment  of  the  state  of  the  ATS 
industry.  This  assessment  is  documented  in  the  discussion  of  Section  3.  The 
highlights  are  that  there  is  a  convergence  of  the  ATS  industry  and  the  information 
technology  community.  The  ATS  community  is  realizing  that  adaptation  and  co¬ 
opting  of  the  trends  and  technologies  of  the  larger  base  is  advantageous  and  the 
ATS  focus  is  concentrated  on  specific  data  acquisition,  test,  and  measurement 
issues. 

2)  Interchangeability  and  interoperability  are  deemed  desirable  by  all 
stakeholders:  end  users,  system  integrators,  and  instrument  suppliers.  The 
concept  of  open  interconnects  is  well  accepted  and  the  idea  of  retaining 
proprietary  interfaces  is  no  longer  considered  a  viable  strategy  by  most 
stakeholders.  Realistic  expectations  are  the  norm  for  interchangeability  and 
interoperability. 

3)  Cooperative  endeavors  are  being  pursued  by  a  variety  of  organizations, 
each  with  awareness  and  intent  to  complement  each  other;  each  with  areas  of 
specialized  interests.  The  IVI  Foundation  is  the  primary  venue  for  GIC  drivers. 
This  organization  has  the  needed  representation  of  end  users  and  instrument 
manufacturers:  it  has  established  processes  and  the  beginning  of  GIC  driver 
specifications;  it  is  using  applicable  standards  of  the  VXIPnP  organization;  it  is 
cooperating  with  ODAS;  and  it  has  liaison  with  other  interested  organizations, 
such  as  the  Test  and  Diagnostics  Consortium,  and  standards  setting  bodies. 

4)  Consensus  for  specifications  is  essential.  The  process  and  participants  of 
the  IVI  Foundation  have  demonstrated  that  consensus  can  be  reached.  It  is  also 
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a  lengthy  and  incremental  process.  As  progress  is  made  on  one  issue,  additional 
issues  are  uncovered  and  worked,  often  with  beneficial  guidance  for  additional 
technical  investigations. 

5)  A  series  of  current  issues  were  uncovered.  These  are  discussed  in 
Section  10. 

6)  While  there  is  a  consensus  as  to  the  desirability  of  GIG  drivers,  there  is  a 
need  for  some  quantified  demonstration  of  economic  benefits.  The  perception  of 
intangible  benefits  is  there.  As  yet,  there  is  no  hard  data. 

7)  Feasibility  for  limited  scope  and  devices  was  demonstrated.  The 
demonstration  helped  uncover  and  confirm  potential  problem  areas  as  conditions 
expand.  The  need  to  handle  namespace  is  a  major  concern. 

8)  The  use  of  COM  objects  will  alleviate  many  of  the  recently  identified 
issues.  However,  there  is  a  need  for  more  detailed  investigation  and 
demonstration  of  the  COM  object  approach.  The  COM  approach  has  not  been 
fully  integrated  into  the  GIC  driver  concept. 

9)  Continued  progress  in  achieving  benefits  of  GIC  drivers  will  require 
significant  support  from  major  end  users  organizations.  The  inherent  benefits  to 
suppliers,  instrument  manufacturers,  and  even  system  integrators  is  much  less 
than  for  end  users.  Consequently,  their  investments  will  be  necessarily  limited. 
Without  a  significant  investment  in  support  to  an  organization  such  as  the  IVI 
Foundation,  progress  will  be  slowed.  National  Instruments  has  invested 
significantly  in  getting  the  IVI  Foundation' going.  It  is  questionable  as  to  how  long 
they  will  continue  the  current  level  of  support  without  having  a  diminishing  effect 
on  the  openness  and  independence  from  proprietary  products. 


12  Estimate  of  Technical  Feasibility 


We  determined  from  our  Phase  I  effort  that  the  GIC  driver  concept  is  feasible. 
Because  of  the  nature  of  this  project,  feasibility  had  to  be  assessed  both  for 
technical  considerations  and  for  acceptance  by  the  necessary  community.  The 
two  views  are  closely  linked  as  technical  approaches  can  alleviate  impediments 
of  individual  stakeholders.  Benefits  increase  with  the  breadth  of  devices 
spanned  at  the  same  time  as  there  are  increased  possibilities  of  incompatibilities 
of  competing  approaches. 
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Modern  software  environments  with  widespread  availability  of  tools  to  manage 
diverse  software,  information  technology  community  wide  development  of 
interface  standards  and  approaches  to  increase  software  reuse,  and  the  willing 
formation  of  industry  groups  intent  on  fostering  interchangeable  and 
interoperable  information  technology  components  all  lead  to  the  conclusion  that 
the  GIC  driver  concept  is  feasible.  Demonstrated  progress  in  developing  and 
achieving  consensus  on  GIC  driver  specifications  for  a  limited  set  of  devices 
further  supports  this  estimate.  There  has  already  been  a  significant  investment 
by  the  ATS  industry  in  the  concept  of  GIC  drivers.  Support  must  continue  to 
maintain  the  momentum  and  to  achieve  measurable  economic  returns  in  order 
that  the  effort  can  continue  to  achieve  widespread  implementation. 
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